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REMARKS 

The following request for reconsideration is submitted in response to the Office 
Action issued on October 6, 2004 (Paper No. 8) in connection with the above-identified 
patent application, and is being filed within the three-month shortened statutory period set for 
a response by the Office Action. 

Claims 1-50 are pending in the present application. The application and such claims 
have not been amended in response to the Office Action. Applicants respectfully request 
reconsideration and withdrawal of the rejection of the claims consistent with the following 
remarks. 

The Examiner has rejected claims 1-50 under 35 USC § 103(a) as being obvious over 
Ginter (U.S. Patent No. 5,910,987). Applicants respectfully traverse the § 103(a) rejection. 

Independent claim 1 as filed recites an apparatus for producing a new ((n)th) black 
box for a digital rights management (DRM) system, where the (n)th black box is for being 
installed in the DRM system and for performing decryption and encryption functions in the 
DRM system. The (n)th black box is produced and delivered to the DRM system upon 
request therefrom and includes a new ((n)th) executable and a new ((n)th) key file. The (n)th 
key file has a new ((n)th) set of black box keys and a number of old sets of black box keys, 
and the request includes an old ((n-l)th) key file having the old sets of black box keys. 

In the apparatus, a code optimizer / randomizer receives a master executable and 
randomized optimization parameters as inputs and produces the (n)th executable as an output. 
Also, a key manager receives the (n-l)th key file and the (n)th set of black box keys as input, 
extracts the old sets of black box keys from the (n-l)th key file, and produces the (n)th key 
file including the (n)th set of black box keys and the old sets of black box keys as an output. 
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The (n)th executable and the (n)th key file are to be forwarded to the requesting DRM 
system. 

Independent claim 10 recites the subject matter of claim 1, although in the form of a 
method. Independent claim 30 recites a method such as that of claim 10 but focuses on 
producing the executable only, and independent claim 38 recites a method such as that of 
claim 10 but focuses on producing the key file only. 

As was set forth in the specification of the present application, a license server only 
issues a license to a DRM system that is 'trusted' (i.e., that can authenticate itself). To 
implement 'trust', the DRM system is equipped with a 'black box' that performs decryption 
and encryption functions for such DRM system. The black box includes a public / private 
key pair, a version number and a unique signature, all as provided by an approved certifying 
authority. The public key is made available to the license server for purposes of encrypting 
portions of the issued license, thereby binding such license to such black box. The private 
key is available to the black box only, and not to the user or anyone else, for purposes of 
decrypting information encrypted with the corresponding public key. 

From time to time, the DRM system may obtain a new and unique ('individualized') 
black box from a black box server or the like, and such black box server delivers the 
individualized black box with a new public / private key pair (PU-BB, PR-BB). The black 
box server may choose to individualize each black box by individualizing an executable 
program file that is delivered to and is resident on the DRM system. Such executable 
program file may for example be a dynamically linked library file or the like. 

The black box server delivers the new individualized black box executable with a new 
public / private key pair (PU-BB, PR-BB). However, the new individualized black box 
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executable should still be able to employ old key sets previously delivered to the DRM 
system in connection with old executables. As may be appreciated, such old key sets are still 
necessary to access older digital content 12 and older corresponding licenses 16 that were 
generated according to such old key sets. Accordingly, with the present invention as recited 
in claims 1-50, such new individualized executable is provided with access to old key sets 
and old public / private key pairs. 

The Ginter reference discloses in copious detail a system and method for secure 
transaction management and electronic rights protection, where electronic appliances such as 
computers participate in the system to ensure that information is accessed and used only in an 
authorized manner. Thus, such electronic appliances provide a distributed virtual distribution 
environment (VDE) that may enforce a secure chain of handling and control. 

As set forth at column 12, such Ginter VDE can employ among other things a 
distributed, secure, "virtual black box" comprised of nodes located at every user site. The 
nodes of such virtual black box can include a secure subsystem having at least one secure 
hardware or software element. In addition, the Ginter VDE can include encryption and 
decryption means, secure communications means employing authentication, digital signing, 
and encrypted transmissions, where the secure subsystems at the user nodes utilize a protocol 
that establishes and authenticates each node's and/or participant's identity, and establishes one 
or more secure host-to-host encryption keys for communications between the secure 
subsystems. 

However, and significantly, the Ginter reference does not at all appreciate that the 
Ginter black box should be or could be periodically updated by obtaining from a centralized 
black box server a new individualized black box and a corresponding new set of black box 
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keys, as is set forth in claims 1 et seq. Consequently, the Ginter reference does not at all 
appreciate, that such new set of black box keys should or could be contained in a key file 
with previous sets of black box keys, as is set forth in claims 1 et seq. so that such previous 
sets of keys are available for use should the need arise. 

According to the Examiner, a code optimizer / randomizer receiving a master 
executable and randomized optimization parameters as inputs and producing the (n)th 
executable as an output such as that recited in claims 1 et seq. is disclosed in the Ginter 
reference at column 117, lines 56-62, column 118, lines 33-35, and column 204, lines 1-10. 
However, such portions detail sub-systems of an SPE (secure processing environment) 503 
located at each Ginter node. In contrast, the recited code optimizer / randomizer is not at 
each DRM system / user's computing device but instead is centrally located to receive 
requests from each DRM system for an (n)th black box. At any rate, Ginter does not in fact 
disclose that a node thereof can or should request a new black box, and thus does not disclose 
that such a request for an (n)th black box should or could be processed by a code optimizer / 
randomizer in the manner recited in claims 1 et seq. 

Also according to the Examiner, a key manager receiving the (n-l)th key file and the 
(n)th set of black box keys as input, extracting the old sets of black box keys from the (n-l)th 
key file, and producing the (n)th key file including the (n)th set of black box keys and the old 
sets of black box keys as an output, such as that recited in claims 1 et seq., is variously 
disclosed at column 12, lines 7-15, column 118, lines 33-35, column 191, lines 18-66, column 
117, lines 64-67, and column 118, lines 35-44. However, and again, such portions also detail 
sub-systems of an SPE (secure processing environment) 503 located at each Ginter node. In 
contrast, and again, the recited key manager is not at each DRM system / user's computing 
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device but instead is centrally located to receive requests from each DRM system for an (n)th 
set of black box keys together with prior sets of black box keys, all in a key file. At any rate, 
Ginter does not in fact disclose that a node thereof can or should request a key file in the 
manner recited in claims 1 et seq., and thus does not disclose that such a request for such a 
key file should or could be processed by a key manager in the manner recited in claims 1 et 
seq. 

Moreover, inasmuch as the Ginter reference does not contemplate updating the black 
box thereof by obtaining a new individualized black box and a corresponding new set of 
black box keys, where the new set of black box keys is contained in a key file with previous 
sets of black box keys, the Ginter system as disclosed does not forward any (n)th executable 
and (n)th key file to a requesting node in the manner set forth in claims 1 et seq. 

Applicants note that the Examiner admits that the Ginter reference fails to explicitly 
discuss extracting old key sets from an old key file and including same in a new key file. As 
was set forth above, Ginter does not and would not disclose same inasmuch as Ginter does 
not update any black box thereof from a centralized server or the like. Nevertheless, the 
Examiner argues that such extracting would be obvious. However, the argument set forth by 
the Examiner to support such claim of obviousness is, essentially, that if a new key set is 
added, then old key sets should be kept because they might still be needed. 

Applicants respectfully submit that such argument fails in two ways. First, such 
argument fails in that the Ginter reference never even appreciates that a new key set should or 
could be provided, and therefore cannot be said to teach keeping old key sets inasmuch as no 
such old key sets exist. Second, such argument fails in that the Ginter reference when 
necessary generates a new version of a key by performing a convoluting process on an old 
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version of such key. Thus, the Ginter reference does not teach or suggest any requirement for 
a brand new key inasmuch as the Ginter nodes can generate new versions of the same key 
from old versions. 

Thus, because the Ginter reference does not disclose, suggest, or teach the 
requirement for obtaining a new black box including a new executable and a new key file in 
the manner set forth in claims 1 et seq., Applicants respectfully submit that such Ginter 
reference cannot be applied to make obvious claims 1, 10, 30, or 38, or any claims depending 
therefrom. Instead, Applicants respectfully submit that such claims are not in fact obvious in 
view of the Ginter reference, and accordingly, Applicants respectfully request reconsideration 
and withdrawal of the § 103(a) rejection. 

In view of the foregoing discussion, Applicants respectfully submit that the present 
application including claims 1-50 is in condition for allowance, and such action is 
respectfully requested. 

Respectfully Submitted, 



Date: January 5, 2005 




Steven H. Meyer 
Registration No. 37,189 



Woodcock Washburn LLP 
One Liberty Place - 46th Floor 
Philadelphia PA 19103 
Telephone: (215) 568-3100 
Facsimile: (215) 568-3439 
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